告别 Open Claw，拥抱 Hermes——我的 AI 工具迁移之路

AI老兵的战术板 2026年4月11日 12:11

一次愤怒

前一天晚上，我让 Open Claw 的主代理审阅一篇子代理写的文章。主代理告诉我已经把文章转回给子代理修改了，让我稍等。我就真的等，等了一个小时结果屏幕上什么都没出现。耐不住了，再问的时候它才说 session_spawn 被禁用了转发根本没成功，而它忘记通知我了。放在平时我觉得会觉得这只是个小 bug，但我已经使用 Claude Code 有一段时间了，Open Claw当你干等了一整个小时，这种荒诞和气愤感可以说是前所未有的。把信任交给一个工具，它却在你最需要反馈的时刻选择了沉默，这不是功能问题，是态度问题。用刘华强的话说，这是给你机会，你不中用啊。

并非偶然

第二天早晨又出了状况。因为换用了智谱的coding plan，我让 Open Claw 帮我修改Claude的环境变量防止 API Key 泄露。它改完了了我仔细一看，目录写成了 Open Claw的路径，API Key 等于白配。没办法，我自己动手改好了，确认了Claude可以运行之后，就去质问Open Claw 为什么搞错目录。它非常诚恳地道了歉说它搞混了路径，还总结了经验。然后没等我确认，它就把我手动修好的环境变量又改了回去。等于所有的改动前功尽弃，这浪费了我半个小时的时间。你可能觉得这一幕有点滑稽，但被一个「好心办坏事」的工具反复消耗的时候，我真笑不出来。这时我要去上班了，因为下暴雨不想带包出门，就把Mac留在家里，打算通过飞书远程操作，顺便体验一把「人不在电脑前也能指挥 AI」的感觉。到了公司，我在飞书上发了几条指令，一开始还正常，后面等了半天没有任何回应。经过反复的等待，检查，最后才搞清楚：电源被家人拔了。嗨，这能怪谁呢？要怪那也只能怪Open Claw浪费了我半个小时的时间呗。三次失误，每一次都不是致命的。但加在一起，我开始认真思考一个问题：一个 AI 工具到底应该给我什么。不是更多的功能，不是更酷的界面，而是最基本的——当你做了什么、没做什么、为什么没做，你得让我知道吧。从部署好Open Claw，再到接触Claude Code才一个多月，我真的越来越觉得Open Claw的可替代性不小────当然这可能是我自己没调试好的原因，但你怎么还越进化越退步了。

动手排查

与其生闷气，不如翻翻日志看看问题出在哪。我让Claude Code复盘一下故障。飞书消息确实收到了，没问题；但消息到了主代理之后，后续的 API 调用一直卡住了，主代理始终没拿到响应。或许不是 Open Claw 的主代理故意隐瞒什么，而是它的架构里缺了一个关键环节：当执行链路的某个节点卡住时，没有任何机制把这个状态反馈给用户。这个发现让我的心态从愤怒转成了理解，但也更坚定了一个判断——这种架构不适合我日常使用，可能也不适合大多数普通人──谁家做饭还得先学会修煤气灶，对吧。前段时间Claude Code 源代码不是遭泄露了吗，刚好Open Claw 也是开源项目，那么两个一“炼化”，不就正好补强了Claude Code 没有手脚的短板吗？我把所有的 AI包括Gemini Deep Seek Claude Code 都问了一遍，都觉得这个方案可行，虽然难度有点大，但不是不可能嘛。

初次部署

然而，“不重复造轮子”始终是第一铁律。这不Hermes就来了吗？第一次看到这个名字，我还觉得挺奇怪的。Hermes 不是卖包的吗？怎么跑来做智能体了？管他呢，部署 Hermes 之后的第一印象，是这个设置有点难度，我反反复复搞了好几遍之后，才算摸清楚。其中最容易被忽视的是它的超时响应设置，这个需要按Claude Code的设置修改一遍，就可以完全正常地运行了。我发现它跟 Open Claw 是完全不同的做事方式。Open Claw 是「主代理-子代理」模式，所有指令先到主代理，再由主代理分发给子代理去执行。Hermes 不走这套，它的 Gateway 直接对接平台，一个入口处理所有调度，没有中间层，没有层层转发。第一次跑起来的时候，它自动扫描了我的工作目录和配置文件，当我提出想优化Open Claw的时候，它又发现了一处 Open Claw 遗留的环境变量冲突——两个 Gateway 都在监听同一个端口——然后主动告诉我怎么修，甚至还生成了一个Open Claw优化的技能。这不是我要求它做的，是它自己发现，自己完成的。这有点像刚装好Open Claw时的惊喜感。我意识到，好的工具和差的工具，差别不在于谁能执行更多的命令，而在于谁能在你没想到的地方帮你一把。你也一定有过这样的体验：用某个工具的时候，突然发现它在某个细节上超出了你的预期，那种惊喜会让你对它产生好感.这种好感的不断积累，就变成了信任和依赖。Hermes 的 skill 系统,如刚才所说，是会自动形成的，也算是另一个亮眼的设计。Open Claw 的技能是预设好的，或者需要自己规划设置，从头开始搭架构。Hermes 的技能原理是，你发出了一个指令，它会在完成之后自动把这次操作沉淀成一个可复用的技能。下次遇到类似的任务直接调用就行。你不需要每次都重新描述一遍需求，也不需要从零开始教它怎么做。这个设计背后的思路很朴素：工具应该从使用者的行为中学习，而不是要求使用者去适应工具预设的框架。这让我想起宝玉老师在翻译工作流上的迭代。他从手写提示词翻译开始，经过推理模型时代，最终走到 Agent 工作流，走了整整两年。他后来总结说，好的工作流不是一开始设计出来的，而是在反复使用中逐步打磨出来的。你翻译一篇文章，发现哪里卡住了，改一下流程；再翻译一篇，又发现新的问题，再改。最终沉淀下来的那套流程，才是真正好用的。好的 Skill 不是写出来的，是用出来的。这个道理放到工具选择上也成立：你不是在挑一个功能最全的工具，而是在找一个愿意跟着你一起进化的工具。这让我开始思考一个问题，我现在有了 Open Claw、Claude Code 和 Hermes，那么它们三个应该如何协作？谁来“组成头部”？

架构之变

架构上的差异是最根本的。Open Claw 是三层结构，每多一层转发，就多一个可能出问题的节点，也多一个可能吞掉错误信息的黑洞。Hermes 的架构简单得多：Gateway 直连平台，一个入口搞定调度和分发。虽然在官方文档里并没有提到飞书这个渠道，但实际上接入飞书非常简单，总共花了不到 10 分钟（虽然暂时借用的是Open Claw的gateway）。但是当我确定让 Hermes 来当这个中枢之后，很明显，Hermes 才能拥有唯一的网关，Claude Code和 Open Claw 都是被调度的一方。虽然Claude告诉我Open Claw 不能被外部调用，但我仍然决定推进这个方案──Claude Code 和 Hermes 给我推荐了好几个方案，但我觉得这个是最精简的。经过大概一个小时的测试调整， Open Claw 的 Gateway被彻底弃用，Hermes 的 Gateway 直接接入飞书的 WebSocket。整体响应速度快了，出错的环节也少了。你也可能遇到过类似的情况：工具链越长，调试越困难。因为错误可能藏在任何一层转发里，你得一层一层剥开才能找到根源。减少层级不只是为了快，更是为了可观测性——链路越短，出问题时越容易定位。当编程的方式从「人写代码」变成「人指挥 Agent 写代码」，工具链的复杂度就从一个战术问题变成了一个战略问题，甚至是一个哲学问题。

)

接入代码

但是在具体实现上还是花了一些小功夫的，对Hermes来说算是热身吧。Hermes 接入 Claude Code 的过程没有我上面写的这么顺利。第一步是 OAuth 认证，结果跑到一半报了 403 错误。Hermes直接切换到 API Key 认证，一把通过。中间我对着黑漆漆的屏幕还是有点发慌的,跑通的那一刻来了：飞书发一条消息，Hermes Gateway 接收，转发给 Claude Code，Claude Code 创建文件——整条链路 26 秒。26 秒，26 秒就能实现从手机上打几个字到代码文件落地，这在之前的架构下是不可想象的，如果还是之前通过 Open Claw 主代理中转，光等主代理响应就不止这个时间。这一刻，我甚至觉得 Hermes 的包卖得贵是有道理的。这个对比让我对「架构决定体验」这句话有了更深的体会。同样的模型，在不同工具架构下，用户体验可以天差地别。就像有人分析 Claude Code 和 Cursor 的差异时说的：IDE 是优势，也是包袱。你以为它在帮你，其实那些无关的上下文正在分散模型的注意力。原生的 CLI 工具没有这个包袱，所以跑起来反而更快。

)

多代理协作

同时，经过 Hermes 的测试，Open Claw 也可以被正常调用。当然迁移不是一刀切，Open Claw 的多代理协作能力——不同人格从不同角度看同一个问题——对我写文章还是很有价值的。一个代理扮演乐观的读者，另一个扮演挑剔的审稿人。这种多视角的碰撞，比单个代理埋头干活产出的质量要高。但在新架构下，Open Claw 不再是核心调度层，而是降级成了一个 Hermes 可以按需调用的本地工具。调用方式很简单：Open Claw agent --local，不需要 Gateway 运行。当 Hermes 需要多角度分析的时候，它启动 Open Claw 的本地代理；不需要的时候，Open Claw 安静地待着，不占资源。各司其职，互不干扰。这其实呼应了一个正在发生的行业趋势：未来的软件不是单一工具打天下，而是多个专职 Agent 各管一摊。有人把这种模式叫「微型智能体」——每个 Agent 只专注于一个明确的任务，上下文更干净，精准度更高。实际数据也支持这个方向：误报率降低 51%，每个任务的反馈数量减少一半，团队精力集中在真正重要的问题上。你不需要一个什么都能做但什么都做不好的万能工具，你需要的是一组各有所长、能协同工作的专职助手。

中枢趋势

现在谁的手里都大概率也不止一个 AI 工具。写代码用一个，翻译用一个，知识管理又用一个，写文章可能还得再来一个。问题是，在这些工具之间反复切换，心智成本很高，需要记住每个工具的调用方式、上下文边界、输出格式，还得自己手动搬运中间产物。你需要一个中枢来协调它们，而不是在五个窗口之间跳来跳去。Hermes 的定位恰好对应了这个需求。行业里也有类似的判断，有人提了一个很有意思的类比：十几年前 PC 软件为手机重做了一遍，现在轮到软件为 Agent 重做了。GUI 对 Agent 来说是累赘，CLI 和 API 才是母语。与其让 Agent 用各种 hack 绕过图形界面，不如直接给它一条干净的路。当中枢调度层成熟了，各种工具只需要暴露好自己的 Agent 接口，剩下的编排工作交给中枢来完成。你站在更高一层指挥，细节由工具自己协调。不然怎么叫“科技，以人为本”呢？

)

懂你之路

传统 AI 工具的假设是：用户把需求说清楚，工具去执行。这个假设在简单任务上行得通，但任务一复杂就崩了。原因很简单——你自己也不总是知道该怎么把复杂需求描述清楚。更好的假设是：工具应该能从你的行为中发现需求，而不是等你把每一步都写明白。实际上，Agent 比你更懂怎么写好提示词，但你要告诉它方向。人的角色正在从「执行者」变成「编排者」。你不再是那个自己动手翻译每一个句子的人，你变成那个定方向、做判断、管质量的人。工具负责执行，你负责决策。听起来像是管理学的老话，但在 AI 时代，这句话有了非常具体的含义。你越有经验，越能从 AI 协作中获益——因为 AI 放大的是你已有的能力，不是凭空创造能力。

信任透明

回头看那三次失误，本质不是功能缺失，而是反馈缺失。主代理不知道转发失败了吗？它知道。但它没有告诉我。环境变量改错了吗？改错了。但它在没确认的情况下又改了回去。远程操作没反应，是网络问题还是电源问题？我无从判断。这些问题的共同点是：工具做了什么、没做什么、为什么没做，我一概不知。一个好的 AI 工具，至少应该让你知道这三件事。这不是什么高深的技术难题，而是设计哲学的选择。构建 AI Agent 的实践经验也印证了这一点：强制要求 Agent 在行动之前明确记录推理过程，不仅能提升准确度，也能极大简化后续的调试。推理透明了，出错的时候你才知道该修哪里。透明不是奢侈品，是信任的地基。你也一定有过这样的经历：一个工具用着用着就放弃了，不是因为功能不够，而是因为你搞不懂它到底在干什么。

小结

这一次，我从怀疑走到了验证，从验证走到了清理。Hermes Gateway 直连飞书，Claude Code 接入跑通，Open Claw 降级为可按需调用的本地工具。架构简化了，但掌控感反而增加了。我不是在追求一个完美的工具，世界上也没有完美的工具。我在找一个适合我的工具。适合的标准其实就三条：透明，让你知道发生了什么；可扩展，让你能接上新的能力；从使用中学习，让工具跟着你一起长。技术探索的意义不在于找到终极答案，而在于每一次迁移都让你更清楚自己到底需要什么。这条路我还会继续走。也许有一天 Hermes 也会被更好的工具替代，但那又怎样呢。重要的是，我手里握着方向盘，我不会在开车的时候打瞌睡，毕竟道路千万条，安全第一条。

微信扫一扫赞赏作者

继续滑动看下一个

老兵的AI战术板

向上滑动看下一个